TCP/IP header compression (V-J header compression) is capable of compressing the TCP/IP header from 40 bytes to as few as three to four bytes through a serial connected Point-to-Point Protocol (PPP) link. The use of such header compression technology is typically not an issue with regard to throughput in a media-reliable environment where the data transferred is rarely lost or distorted due to physical interference and other impairments.
However in an unreliable transmission link environment, such as in a wireless data transmission environment, the noise is typically bursty. Consequently, data packet loss is a common occurrence. For example, in first generation wireless code division multiple access (CDMA) a radio link protocol (RLP) is used as the link layer below the PPP layer for data transfer. RLP is a best-effort protocol, and only conducts a few rounds of recovery for lost frames. Furthermore, RLP will deliver corrupted frames to a higher layer if it cannot recover the lost frames.
V-J header compression relies on previously received in-sequence correct packets to restore the information from the compressed TCP/IP header. As a result, if TCP/IP V-J header compression is enabled during CDMA wireless data transfer, a single data packet loss can result in the failure of decoding of all later received data packets. The total size (in bytes) of the later received packets can be up to the entire announced TCP receiver window size. The decoding failure is indicated as an incorrect TCP checksum due to an incorrect restored TCP sequence number in the TCP header part.
Section 4.2 of RFC 1144 is entitled “Error Recovery”, and suggests techniques for causing the decompressor to again begin generating valid packets after an occurrence of a CRC error.
At present, those data packets with an incorrect TCP checksum (although the data payload is still correct) are discarded quietly. Also, since the data packets are discarded quietly by the receiver, no TCP acknowledgment (ACK) packets are sent back to trigger the peer TCP (i.e. the data sender) fast retransmission/recovery algorithm. This problem results in wasting the air channel resource and also in a lower data transfer throughput.
FIG. 1 shows a typical TCP/IP/PPP protocol stack implementation. Assume that there exists a block of user data 1 that is required to be delivered to a peer application. The user data 1 is first delivered to the TCP layer 2. The TCP layer 2 may segment the block of user data 1 into several segments. For each segment, the TCP layer 2 puts the data in the payload of a frame, and wraps it with a TCP header 2A into a TCP frame. FIG. 2 shows a conventional TCP frame format, which has a 16-bit checksum part in the header part. Next, the TCP layer 2 delivers the entire TCP frame to the IP layer 3. The IP layer 3 considers the entire TCP frame as data, and places it into the payload part of a frame, adds an IP header 3A, and thus generates an IP frame. FIG. 3 shows a conventional IP frame format, which has a 16-bit header checksum. The IP frame is then delivered to the PPP layer 4 and placed into a PPP payload part and wrapped into a PPP frame having a PPP header 4A. FIG. 4 shows a conventional PPP frame format, which has a 16-bit frame-check-sequence (FCS, which is a 16-bit CRC check). The PPP frame is delivered to a lower layer to be passed to the peer. For example, in a first generation wireless CDMA system the lower layer is the RLP layer and an IS2000/IS-95 physical layer.
From FIGS. 2 and 3 it can be seen that the IP header and the TCP header both consist of 20 bytes. If the V-J header compression is enabled, the 40 total bytes of TCP/IP headers can be compressed into about three (one byte of flag bits and two bytes of TCP checksum) to four bytes to transfer only the difference between the frames.
In a wireless environment, the data transfer may often proceed in the following exemplary manner:
Frame #1234567XXYZZZZwhere:X indicates a received good and in-sequence frame;Y indicates a corrupted PPP frame due to RLP layer data loss or corruption; andZ indicates a received out-of-sequence frame.
For the corrupted Y frame #3, some bytes (or bits) in the frame may be either lost or altered, resulting in the frame usually not passing the PPP FCS check. As a result, this frame will be discarded in the PPP layer.
With V-J header compression turned off, the Z frames (frames 4, 5, 6 and 7) will have a good PPP layer FCS, a good IP header check sum and TCP check sum. Each time it receives a Z frame, the TCP receiver will store the frame in a buffer. It will also send a TCP ACK package back to the data sender for informing the sender that it has received all the data packets up to packet number 3. For example, when the data receiver receives four Z frames, such as frames 4, 5, 6 and 7, it will send four TCP ACK frames back to the data sender, all with the same acknowledgment number of packet #2. When the data sender receives three or more consecutive TCP ACK frames acknowledging the same packet number 2, it will immediately know that packet number 3 is lost. The data sender will then immediately re-transmit data packet number 3 and only re-transmit packet number 3. When the data receiver receives the corrupted frame #3, it sends a TCP ACK to acknowledge all of the data up to frame #7. Consequently, all of the Z frames are useful. This is referred to as the TCP fast-retransmission and fast-recovery algorithm, as defined in RFC 2581. Nearly all TCP protocol stacks have this algorithm implemented.
Considering now the case where V-J header compression is turned on (enabled), the frames #4, 5, 6 and 7 will still all have good PPP layer frame check sums (FCS), and are passed to the IP layer. In the IP layer, since all packets for one TCP connection have the same IP header information, the IP header can be successfully restored, and the IP header check is also correct. As a result, the data can be passed to TCP layer. However, since frame #3 was lost, and since the TCP layer relies on the in-sequence frames to decode the TCP sequence number, all of the Z frames will exhibit a bad TCP layer header, which results to an erroneous TCP checksum. These Z frames are thus discarded immediately. Consequently, although the Z frames all contain good data, they are assumed to be bad because of the failure to correctly restore the TCP headers and are thus not used. Furthermore, there is no TCP ACK frame sent back to the data sender, and the TCP fast-retransmission and fast-recovery algorithm is not triggered. In this case the data sender is required to re-transmit all of the frames 4, 5, 6 and 7 by relying on its re-transmission timer timing out, which can result in a considerable delay before the re-transmission occurs. During this delay period no data is transmitted, resulting in a reduced data transfer throughput.
It can thus be appreciated that when a TCP/IP packet is lost due to V-J header compression being turned on, the resulting indication is that the TCP checksum is incorrect for the remainder of the TCP window segments. As a result, the TCP layer 2 quietly discards the packets that have incorrect checksum, thereby wasting the network channel capacity. As the conservation of channel bandwidth is an important consideration in wireless communications systems, such as modern cellular-type communications systems, this problem results in a number of disadvantages for both the users and the network operators.